When we plan for changes (especially big changes). It’s always very tempting to think about all the place that we need to update, basically a complete overhaul of things. However, we should not do that.
A complete overhaul means a lot of work that requires a tremendous amount of time and men power, which we generally don’t have or want to avoid as much as possible
It’s always better to add changes gradually and release little by little to track success and impact at an early
What we should do is to be mindful/aware of our final goal, and our current state across the platform, and know what can we do to reach that goal. We also need to know our current road map item and identify if we already have something planned for our current changes, and know that we are not there yet (e.g maybe it’s a big change and we don’t know if we actually want to do that yet and we need more data/metrics). But we still need to something (starts small and track success/impact), we should find an easiest and fastest way to implement our changes, even if it’s probably not the best way or best place to implement it, but it’s easy and fast and most importantly, it’s easy to just delete it when we reach the point when we decide to implement the stuff on the roadmap.
Brain Storm session guide
Before rushing into any complex implementation
Need to have a brainstorm session where multiple people can bounce off between ideas
Try to list down all the Pros and Cons, and may even compare between approach to see if it is actually a Cons. For example, a Cons may not be a con if it is a limitation that all approach shares.
Weight the Pros and Cons to pick the most suitable option
However, things may not be easy as it seems
To do any of the above effectively, we need to have good understanding of all the current service and technology that we already have
We also need to be aware of the target date, and avoid doing anything that may delay the target date. Always try go for quick win (not just quick win but more like how much can we still accomplish without the complicated stuff, can it be delayed to implement after the target date)
Whenever we discuss about an approach, we can have many ideas about how to resolve a Cons, and then we may go really deep into that approach with that Cons (one solution may lead to another Cons of that solution). We call this branching of ideas. We may and we will have multiple branches and decide to explore each one at a time, always try not to go too deep cause this is like we try an approach and we just kinda try too much to make it work, while it’s better to go back and explore another branch. The important thing is that we have to know when to go back, and where to go back.
While discussing, we can come up with thing that based on our own assumption, we can explore that idea and see if it is worth exploring, or if it is not that big/unlikely we can just ignore it and add metrics to verify our assumption.